Quality of Service to Over the Top Applications Used with VPN

ABSTRACT

Conventional quality of service (QoS) treatment is extended to over-the-top (OTT) applications transmitting data over a commercial wireless network via a virtual private network (VPN) tunnel. An over-the-top (OTT) application server and a VPN client/server routing data to/from that OTT application server via a VPN tunnel, are integrated with a quality of service (QoS) server to enable the OTT application server and/or VPN client/server to request and get desired QoS treatment for application data routed by the OTT application server over the VPN tunnel. The QoS server forwards QoS rules received in a QoS request message to a policy and charging rules function (PCRF) on the OTT application/VPN client devices&#39; home mobile network operator (MNO). If the client device is roaming, the PCRF on the home MNO forwards QoS rules to a PCRF on a serving MNO. QoS treatment is then carried out by the PCRF in a conventional manner.

The present invention is a continuation-in-part of U.S. application Ser.No. 14/032,913, filed Sep. 20, 2013, entitled “Mechanisms For Quality ofService to Over the Top Applications For Use in Commercial WirelessNetworks”; which claims priority from U.S. Provisional No. 61/714,944,filed Oct. 17, 2012, entitled “Mechanisms for Quality of Service to Overthe Top Applications For Use In Commercial Wireless Networks”. Thepresent application also claims priority from U.S. Provisional No.61/815,976, filed Apr. 25, 2013, entitled “Quality of Service to Overthe Top Applications Used with VPN”; and from U.S. Provisional No.61/829,745, filed May 31, 2013, entitled “Quality of Service to Over theTop Applications Used with VPN”. The entirety of all four of theseapplications are expressly incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates generally to Quality of Service (QoS) control forVirtual Private Network(s) (VPNs) established between smart phones andprivate networks (e.g., enterprise or agency intranet) over Long TermEvolution (LTE) commercial wireless networks. These VPN(s) may be usedby smart phone applications to access data in the cloud in a securemanner and typically involve tunneling of original application IPpackets in an encrypted fashion inside of an outer IP packet.

2. Background of Related Art

Verizon Wireless™ has recently become the first commercial serviceprovider to fully launch a network with Long Term Evolution (LTE) 4Gwireless broadband technology. Long Term Evolution (LTE) 4G wirelessbroadband technology is a recent technology that supports a fast andefficient all-Internet Protocol (IP) network (i.e., a network thatprovides services, e.g., voice, video, data, messaging, etc., solelyover the Internet). It is expected that the majority of commercialservice providers will also adopt an all-Internet Protocol (IP) networkat some time in the near future.

As the future of technology gears toward an all-IP network, the numberof available over-the-top (OTT) applications is expected to increase. Anover-the-top (OTT) application is an application that uses a datachannel provided by an Internet service provider (ISP) to connect to theInternet instead of using any special data handling features or networkservices offered thereby.

In accordance with conventional technology, over-the-top (OTT)application data is sometimes routed over a commercial wireless networkvia a virtual private network (VPN) tunnel (which involves the tunnelingof original IP packets inside outer IP packets in an encrypted fashion).A virtual private network (VPN) tunnel provides additional transmissionsecurity to over-the-top (OTT) application data, which is especiallyhelpful to over-the-top (OTT) applications that lack end-to-endencryption on their network connections.

Quality of service (QoS) refers to a set of performance characteristicsby which a commercial wireless network is expected to convey datatraffic to and from a client (quality of service (QoS) controlmechanisms are applied to both the wireless and wireline components of acommercial network). Specific performance characteristics may includethroughput (i.e. data quantity transmitted per unit time), latency (i.e.time delay between transmission and receipt of data), loss rate (i.e.frequency by which a commercial wireless network fails to deliverportions of transmitted data), jitter (i.e. a measure of variance ofother characteristics), etc.

Currently, there exist several inherent limitations to the quality ofservice (QoS) treatment that a commercial wireless network is able toprovide its' clients. For example, the maximum throughput that acommercial wireless network is able to provide across all clients isdependant on: a spectrum allocation held by the commercial wirelessnetwork, a backhaul infrastructure setup between cellular towers andfixed infrastructure within the commercial wireless network, the numberof cellular towers in use within the commercial wireless network, thesize of a footprint assigned to each cellular tower in use within thecommercial wireless network, and any sources of electromagneticinterference within the commercial wireless network.

It is found that applications (e.g. smart phone applications) typicallyrun better (i.e., perform more objective work per unit time and providebetter user experience) when they are receiving a higher level ofquality of service (QoS) treatment from a commercial wireless network asopposed to a lower level of quality of service (QoS) treatment.Consequently, many clients/service providers enter into contractualagreements with commercial wireless networks to ensure that they receivea data conveyance that is at-or-above a desired minimum performancelevel. For example, a commercial wireless network may agree (in exchangefor monetary compensation) to provide a minimum of 12 kilobit/secondthroughput and a minimum of 0.1 second latency to a client userequipment (UE) that desires to receive real-time streaming video feedover that wireless network.

Commercial wireless networks use well-known internal techniques toensure that contracted clients receive a pre-negotiated level of qualityof service (QoS) treatment. For example, a network operator may delaytransmitting data for one low-level quality of service (QoS) client toprioritize data transmission for another high-level quality of service(QoS) client. Likewise, a network operator may discard data packetstransmitted to/from one low-level quality of service (QoS) client morefrequently, to ensure data conveyance for another high-level quality ofservice (QoS) client.

Unfortunately, vendors of over-the-top (OTT) applications and associateddata do not typically enter into contractual quality of service (QoS)agreements with commercial wireless networks (e.g. Long Term Evolution(LTE) networks). Therefore, over-the-top (OTT) applications aretypically unable to benefit from quality of service (QoS) controlmechanisms (e.g, priority, packet delay, guaranteed bit rate, etc.)available thereon. Instead, most over-the-top (OTT) applications (e.g.,Skype, Netflix, etc.) provide services on a best-effort basis (i.e.,data delivery, efficiency not guaranteed).

Differentiated Services (DiffServ) has defined a mechanism forclassifying and managing network traffic on modern Internet Protocol(IP) networks, for the purposes of providing quality of service (QoS)treatment thereon. In particular, DiffSery uses a 6 bit field (i.e. a DSfield) in an IP header for packet classification purposes.

In accordance with conventional DiffSery technology, a DS field may beinfluenced (set) by an application generating IP packets. Moreover, avirtual private network (VPN) client may copy a DiffSery header from anincoming application IP packet (that will eventually be encapsulated) toan IP header of a tunneling IP packet to extend DiffSery quality ofservice (QoS) treatment to a virtual private network (VPN) environment.

However, though smart phone applications, application cores in thecloud, and virtual private network (VPN) software may all influence thesetting of a DS field, there is no guarantee that an Internet Protocol(IP) network (e.g. a long term evolution (LTE) network) will honor a DSfield setting and provide desired quality of service (QoS) treatment,being that: first, the honoring of a DS field is not mandated by currentstandards and, second, triggering quality of service (QoS) treatment insuch a fashion defeats the purpose of quality of service (QoS) controlas, conceivably, all types of data traffic flowing through an IP networkcould be marked for preferential treatment by a source application.

As commercial wireless networks begin carrying data for over-the-top(OTT) mission critical applications, such as applications used byemergency dispatch personnel and emergency first responders, abest-effort treatment of over-the-top (OTT) applications will no longerbe acceptable. This is especially true in times of disaster, whennetworks are likely heavily congested. Hence, a successful means ofextending quality of service (QoS) treatment to over-the-top (OTT)applications, including over-the-top (OTT) applications transmittingdata over a virtual private network (VPN) tunnel, is needed.

SUMMARY

A method and apparatus for extending conventional quality of service(QoS) treatment to over-the-top (OTT) applications transmitting dataover a commercial wireless network via a virtual private network (VPN)tunnel, comprises a quality of service (QoS) server. In accordance withthe principles of the present invention, an over-the-top (OTT)application server and a virtual private network (VPN) client/serverrouting data to/from the over-the-top (OTT) application server over avirtual private network (VPN) tunnel, are each integrated with a qualityof service (QoS) server. Following integration, the over-the-top (OTT)application server and/or the virtual private network (VPN)client/server may request and get desired quality of service (QoS)treatment for application data routed by the over-the-top (OTT)application over the virtual private network (VPN) tunnel. The presentinvention is applicable to both single-tenant virtual private network(VPN) tunnels and multi-tenant virtual private network (VPN) tunnels.

In accordance with the principles of the present invention, asingle-tenant virtual private network (VPN) tunnel (i.e. a virtualprivate network (VPN) tunnel that is treated as a single application) isonly permitted one quality of service (QoS) designation at a time.Hence, a quality of service (QoS) designation requested for/by anapplication routing data over a single-tenant virtual private network(VPN) tunnel is applied to all application data routed over that virtualprivate network (VPN) tunnel.

Alternatively, applications routing data over a multi-tenant virtualprivate network (VPN) tunnel are acknowledged independently and assignedtheir own individual quality of service (QoS) designations. Hence, aquality of service (QoS) designation requested for/by an applicationrouting data over a multi-tenant virtual private network (VPN) tunnel isapplied to application data routed by that requesting over-the-top (OTT)application, only. In accordance with the principles of the presentinvention, a multi-tenant virtual private network (VPN) tunnel maydefine a default quality of service (QoS) designation for applicationdata routed to/from applications that have not indicated a preferredquality of service (QoS) designation.

In accordance with the principles of the present invention, the qualityof service (QoS) server forwards desired quality of service (QoS) rulesembedded in a quality of service (QoS) request message to a policy andcharging rules function (PCRF) on a requesting over-the-top (OTT)application/virtual private network (VPN) client devices' home mobilenetwork operator (MNO). If a client device is roaming, then the policyand charging rules function (PCRF) on the client devices' home mobilenetwork operator (MNO) forwards received quality of service (QoS) rulesto a policy and charging rules function (PCRF) serving the clientdevice. Quality of service (QoS) treatment is then carried out in aconventional manner by the serving policy and charging rules function(PCRF).

In accordance with the principles of the present invention, a connectionbetween a quality of service (QoS) server and a policy and chargingrules function (PCRF) is preferably established via a diameter Rxinterface. Accordingly, the primary function of a quality of service(QoS) server is to translate diameter protocol messages to othercommunication mediums and vice versa.

In accordance with the principles of the present invention, anover-the-top (OTT) application must provide identification details andregister services and application characteristics with the quality ofservice (QoS) server before that application is permitted to requestquality of service (QoS) treatment therefrom. During registration withthe quality of service (QoS) server, an over-the-top (OTT) applicationis required to provision one or more quality of service (QoS)application profiles, each indicating a desired level of quality ofservice (QoS).

In accordance with the principles of the present invention, a virtualprivate network (VPN) client/server must furnish relevant tunnelinginformation to the quality of service (QoS) server before that virtualprivate network (VPN) client/server is permitted to request quality ofservice (QoS) treatment therefrom. Relevant tunneling information variesdepending upon a type of virtual private network (VPN) tunnelestablished. In particular, during registration with the quality ofservice (Qos) server, a single-tenant virtual private network (VPN)tunnel is required to provision identification details and one or morequality of service (QoS) application profiles on the quality of service(QoS) server. Alternatively, during registration with the quality ofservice (Qos) server, a multi-tenant virtual private network (VPN)tunnel must provision identification details and adequate tunnelinginformation on the quality of service (QoS) server, but need notpreprovision any quality of service (QoS) application profiles.Tunneling information furnished to the quality of service (QoS) serverfor a multi-tenant virtual private network (VPN) tunnel must enable thequality of service (QoS) to identify IP packets associated withapplication data routed thereover.

In accordance with the principles of the present invention, a quality ofservice (QoS) application profile ID identifying a particular quality ofservice (QoS) application profile (i.e. quality of service (QoS) rules),is included in each quality of service (QoS) request message sent to thequality of service (QoS) server. A quality of service (QoS) applicationprofile ID indicates to the quality of service (QoS) server a particularquality of service (QoS) application profile to invoke.

When an over-the-top (OTT) application server detects a termination ofsignaling or service on an over-the-top (OTT) application client device,the over-the-top (OTT) application server sends a quality of service(QoS) termination message to the quality of service (QoS) server, toindicate that reserved quality of service (QoS) values may be terminatedon the client devices' home mobile network operator (MNO).

Likewise, a virtual private network (VPN) client/server must inform thequality of service (QoS) server when a virtual private network (VPN)tunnel has terminated.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of the present invention will become apparent tothose skilled in the art from the following description with referenceto the drawings, in which:

FIG. 1 depicts an exemplary network structure for extending conventionalquality of service (QoS) treatment to over-the-top (OTT) applicationsrouting data over a commercial wireless network via a virtual privatenetwork (VPN) tunnel, in accordance with the principles of the presentinvention.

FIG. 2 depicts an exemplary quality of service (QoS) serverarchitecture, in accordance with the principles of the presentinvention.

FIG. 3 depicts an exemplary process flow for extending quality ofservice (QoS) treatment to over-the-top (OTT) applications routing dataover a commercial wireless network via a virtual private network (VPN)tunnel, in accordance with the principles of the present invention.

FIG. 4 depicts conventional encryption and encapsulation of an originalIP packet, in accordance with conventional IPSec virtual private network(VPN) technology.

FIG. 5 depicts a conventional single-tenant virtual private network(VPN) tunnel.

FIG. 6 depicts a conventional multi-tenant virtual private network (VPN)tunnel.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The present invention extends conventional quality of service (QoS)treatment to over-the-top (OTT) applications transmitting data over acommercial wireless network (e.g. a long term evolution (LTE) network)via a virtual private network (VPN) tunnel.

New wireless standards, such as long term evolution (LTE), only specifydata connectivity, and do not specify any applications. Applications,rather, are expected to be facilitated via carrier-hosted applicationframeworks (e.g. an internet multimedia system (IMS)).

To ensure that applications carried out via carrier-hosted applicationframeworks operate at a desired level of quality of service (QoS) (e.g.packet delay, priority, etc.), new wireless standards have defined apolicy and charging rules function (PCRF). A policy and charging rulesfunction (PCRF) is a network element (in a long term evolution (LTE)packet core) that may be accessed by carrier-hosted applicationframeworks (e.g. IMS) (via a diameter protocol based interface (Rx)) forthe purposes of providing quality of service (QoS) treatment toapplications.

Unfortunately, applications to which policy and charging rules functions(PCRF) are expected to extend quality of service (QoS) treatment, do notinclude over-the-top (OTT) applications. An over-the-top (OTT)application is an application that provides services/content to a clientuser equipment (UE) over the Internet, absent the involvement of anInternet service provider (ISP). Hence, conventional over-the-top (OTT)applications are not facilitated via carrier-hosted applicationframeworks, and are thus not able to benefit from quality of service(QoS) treatment available on today's commercial wireless networks.Rather, conventional over-the-top (OTT) applications are typicallyforced to operate on a best-effort basis (i.e. data delivery, efficiencynot guaranteed).

With the future of technology gearing towards an all IP-network (e.g. along term evolution (LTE) network), over-the-top (OTT) applications areexpected to become increasingly common. As commercial wireless networksbegin carrying data for over-the-top (OTT) mission criticalapplications, such as those applications used by emergency dispatchpersonnel and emergency first responders, a best effort treatment ofover-the-top (OTT) application data will no longer be acceptable.

The present invention expands a method of extending conventional qualityof service (QoS) treatment to over-the-top (OTT) applications routingdata over a commercial wireless network, as disclosed in co-pending andco-owned U.S. patent application Ser. No. 14/032,913, filed Sep. 20,2013, entitled: “MECHANISMS FOR QUALITY OF SERVICE TO OVER THE TOPAPPLICATIONS FOR USE IN COMMERCIAL WIRELESS NETWORKS”, claiming priorityfrom U.S. Provisional Application No. 61/703,554, filed Sep. 20, 2012,entitled: “MECHANISMS FOR QUALITY OF SERVICE TO OVER THE TOPAPPLICATIONS FOR USE IN COMMERCIAL WIRELESS NETWORKS”, and from U.S.Provisional No. 61/714,944, filed Oct. 17, 2012, entitled “MECHANISMSFOR QUALITY OF SERVICE TO OVER THE TOP APPLICATIONS FOR USE INCOMMERCIAL WIRELESS NETWORKS”, all of which are explicitly incorporatedherein by reference. Mechanisms for quality of service control disclosedin U.S. Ser. No. 14/032,913 address a scenario wherein an over-the-top(OTT) application connects to a cloud based application infrastructuredirectly.

The present invention addresses a variation of the scenario described inU.S. application Ser. No. 14/032,913. In particular, the presentinvention addresses a scenario wherein an over-the-top (OTT) applicationclient on a user equipment (UE) is connected to a cloud basedover-the-top (OTT) application server via a virtual private network(VPN) connection. A conventional virtual private network (VPN)connection provides additional transport security to over-the-top (OTT)application data traversing a commercial wireless network, by tunnelingoriginal IP packets inside outer IP packets in an encrypted fashion.Mechanisms for establishing a virtual private network (VPN) tunnelappropriate to convey over-the-top (OTT) application data are well knownto those skilled in the art.

In accordance with the principles of the present invention, conventionalquality of service (QoS) treatment is extended to over-the-top (OTT)applications transmitting data over a commercial wireless network (e.g.a long term evolution (LTE) network) via a virtual private network (VPN)tunnel, without requiring that modifications be made to over-the-top(OTT) applications, and without requiring that over-the-top (OTT)application developers negotiate separate quality of service (QoS)agreements with mobile network operators (MNO). Moreover, the presentinvention extends conventional quality of service (QoS) treatment tovirtual private networks (VPN) carrying over-the-top (OTT) applicationdata without burdening virtual private networks (VPN) with networkintegration aspects, such as: knowledge of user location, knowledge of apolicy and charging rules function (PCRF), knowledge of a long termevolution (LTE) packet core, etc.

In accordance with the principles of the present invention, anover-the-top (OTT) application server and a virtual private network(VPN) client/server carrying data to/from that over-the-top (OTT)application server over a virtual private network (VPN) tunnel, are eachintegrated with an inventive quality of service (QoS) server. Followingintegration, the over-the-top (OTT) application server and/or thevirtual private network (VPN) client/server may send a quality ofservice (QoS) request message to the inventive quality of service (QoS)server (via an appropriate virtual private network (VPN) client/serverinterface or over-the-top (OTT) application interface) to request thatdesired quality of service (QoS) treatment (identified by a quality ofservice (QoS) application profile ID) be applied to application datarouted by the over-the-top (OTT) application over the virtual privatenetwork (VPN) tunnel.

The inventive quality of service (QoS) server forwards quality ofservice (QoS) rules embedded in a quality of service (QoS) requestmessage to a policy and charging rules function (PCRF) residing on arequesting over-the-top (OTT) application/virtual private network (VPN)client devices' home mobile network operator (MNO). If the client deviceis roaming, then the policy and charging rules function (PCRF) on thatdevice's home mobile network operator (MNO) forwards quality of service(QoS) rules to a policy and charging rules function (PCRF) serving theclient device. Quality of service (QoS) treatment is then carried out bythe policy and charging rules function (PCRF) in a conventional manner.

In accordance with the principles of the present invention, anover-the-top (OTT) application server and/or a virtual private network(VPN) client/server may modify a previously requested level of qualityof service (QoS) treatment, when a previously requested level of qualityof service (QoS) treatment is not resulting in desired performance.

The inventive solution may be applied to various virtual private network(VPN) technologies, including: a layer 2 tunneling protocol (L2TP)technology, a point-to-point tunneling protocol (PPTP) technology, atransport layer security/virtual private network (VPN) technology, etc.However, for illustrative purposes, the present invention is describedherein via use of an IPSec virtual private network (VPN) technologyconfigured in tunnel mode. In accordance with conventional IPSec virtualprivate network (VPN) technology, all IP datagrams (including bothdatagram header and datagram packet) routed over a virtual privatenetwork (VPN) tunnel are first encapsulated inside new IP datagrams withIPSec headers.

FIG. 4 depicts conventional encryption and encapsulation of an originalIP packet, in accordance with conventional IPSec virtual private network(VPN) technology.

In particular, an original IP packet 420 (including an original IPheader 440 and an original application payload 450) is encrypted 400 a,400 b and encapsulated in an outer IP packet 410 with an IPSec header430 before it is routed over a conventional IPSec virtual privatenetwork (VPN) tunnel. A virtual private network (VPN) client/server alsointerprets an original IP packet 420 and assigns an appropriate securityparameter index (SPI) value (in accordance with a preconfigured securityparameter index (SPI) value) thereto before routing the IP packet over avirtual private network (VPN) tunnel. A security parameter index (SPI)value serves as an index to a conventional security association database(SADB) (i.e. a database that maintains information for a virtual privatenetwork (VPN) tunnel) maintained for a virtual private network (VPN)tunnel. A security association database (SADB) preferably includes someor all of the following information: security association information(i.e. security parameter index, IPSec protocol, IP destination address)and security policy information (i.e. IP source address, IP destinationaddress, fully qualified domain name, source port number, destinationport number, quality of service (QoS) application profile ID).

The present invention is applicable to both single-tenant virtualprivate network (VPN) tunnels and multi-tenant virtual private network(VPN) tunnels.

FIG. 5 depicts a conventional single-tenant virtual private network(VPN) tunnel.

In particular, a single-tenant virtual private network (VPN) tunnel 500is always treated as a single application, regardless of how manyapplications 510 actually utilize the tunnel 500. Therefore, asingle-tenant virtual private network (VPN) tunnel 500 is only permittedone quality of service (QoS) designation 540 at a time. In accordancewith the principles of the present invention, a quality of service (QoS)designation requested for/by an application routing data over asingle-tenant virtual private network (VPN) tunnel 500 is applied to allapplication data 510 routed over that virtual private network (VPN)tunnel 500.

FIG. 6 depicts a conventional multi-tenant virtual private network (VPN)tunnel.

As portrayed in FIG. 6, applications 530 transmitting data over amulti-tenant virtual private network (VPN) tunnel 520 are acknowledgedindependently and may thus be assigned their own individual quality ofservice (QoS) designations 550. A quality of service (QoS) designation550 requested for/by an application routing data over a multi-tenantvirtual private network (VPN) tunnel 500 is only applied to applicationdata routed by that application.

FIG. 1 depicts an exemplary network structure for extending conventionalquality of service (QoS) treatment to over-the-top (OTT) applicationsrouting data over a commercial wireless network via a virtual privatenetwork (VPN) tunnel, in accordance with the principles of the presentinvention.

In particular, as depicted in FIG. 1, a quality of service (QoS) server100 is configured to directly interface with one or more commercialwireless networks 102 a, 102 b via a conventional policy and chargingrules function (PCRF) (i.e. an IP multimedia subsystem (IMS)/long termevolution (LTE) network component) 104. In accordance with theprinciples of the present invention, a connection between a quality ofservice (QoS) server 100 and a policy and charging rules function (PCRF)104 is preferably established via a diameter Rx interface 106 (3GPPspecifications 29.209, 29.214). Hence, the primary function of a qualityof service (QoS) server 100 is to translate diameter protocol interface106 messages to other communication mediums and vice versa.

Once a connection is established between a policy and charging rulesfunction (PCRF) 104 and the quality of service (QoS) server 100, theinventive quality of service (QoS) server 100 takes on the role of aspecial application function (AF) connected on the backend (i.e. notaccessible to a user) 110 of one or more disparate applications. Thequality of service (QoS) server 100 also establishes a connection with avirtual private network (VPN) server 112 and/or virtual private network(VPN) client 118, when application data exchanged between anover-the-top (OTT) application client 120 and an over-the-top (OTT)application server 110 happens over a virtual private network (VPN)tunnel 114.

As depicted in FIG. 1, the inventive quality of service (QoS) server 100uses a secure virtual private network (VPN) client/server interface 116to interface with a virtual private network (VPN) client 118/server 112on either end of a virtual private network (VPN) tunnel 114. Inaccordance with the principles of the present invention, virtual privatenetwork (VPN) clients 118/servers 112 use the virtual private network(VPN) client/server interface 116 to provide relevant tunnelinginformation to the quality of service (QoS) server 100. Relevanttunneling information enables the quality of service (QoS) server 100 toidentify IP packets associated with over-the-top (OTT) application datatransmitted over a virtual private network (VPN) tunnel 114.

In accordance with the principles of the present invention, a virtualprivate network (VPN) tunnel 114 is established between a virtualprivate network (VPN) client 118 on a user equipment 108, and a fixedinfrastructure virtual private network (VPN) server 112, so that datatraffic transmitted to/from one or more over-the-top (OTT) applicationclients 120 on the user equipment (UE) 108 may traverse the virtualprivate network (VPN) tunnel 114. A virtual private network (VPN) tunnel114 encrypts and encapsulates an original IP packet inside an outer IPpacket while the IP packet is traversing a commercial wireless network.An underlying commercial wireless network 102 a, 102 b is typicallyconfigured to provide a certain level of quality of service (QoS)treatment to traffic traversing a virtual private network (VPN) tunnel114.

In accordance with the principles of the present invention, the qualityof service (QoS) server 100 must be able to communicate with backendapplications 110, carrier policy and charging rules (PCRF) function(s)104, and virtual private network (VPN) clients 118/servers 112,simultaneously. Simultaneous communication may be permitted via afirewall setting and/or other network configuration rules.

In accordance with the principles of the present invention, a quality ofservice (QoS) server 100 may be located separate from a mobile networkoperator (MNO) 102 a, 102 b or co-located with a mobile network operator(MNO) 102 a, 102 b. Possible mobile network operator (MNO) integrationtargets currently include: a universal mobile telecommunications system(UMTS), long term evolution (LTE) technology, an evolved-universalmobile telecommunications system (E-UMTS), long term evolution (LTE)technology advanced, and Wi-Fi. The quality of service (QoS) server 100may easily be extended to support additional network interfaces astechnology evolves.

FIG. 2 depicts an exemplary quality of service (QoS) serverarchitecture, in accordance with the principles of the presentinvention.

In particular, as portrayed in FIG. 2, the inventive quality of service(QoS) server 100 interacts with a mobile network operator (MNO) policyand charging rules function (PCRF) interface (a diameter protocolinterface) 106, an over-the-top (OTT) application interface 210, anumber portability database (NPDB) interface 240, and a virtual privatenetwork (VPN) client/server interface 116 to extend quality of service(QoS) treatment to applications routing data over a commercial wirelessnetwork 102 a, 102 b via a virtual private network (VPN) tunnel 114.

In accordance with the principles of the present invention, the qualityof service (QoS) server 100 maintains profiles and information forover-the-top (OTT) applications in a local application informationdatabase 220, tunneling and IP packet information for registered virtualprivate network (VPN) tunnels in a local virtual private network (VPN)tunneling information database 250, and home mobile network operator(MNO) information for over-the-top (OTT) application client devices in alocal mobile network operator (MNO) information database 230.

If by chance the quality of service (QoS) server 100 is not able to findhome mobile network operator (MNO) information for a requesting clientdevice 108 in the local mobile network operator (MNO) informationdatabase 230, then the quality of service (QoS) server 100 accesses anumber portability database (NPDB) interface 240 to retrieve relevanthome mobile network operator (MNO) information from an external numberportability database (NPDB) 270.

The over-the-top (OTT) application interface 210, as depicted in FIG. 2,is designed to operate over a secure, transport layer security(TLS)/secure sockets layer (SSL) communications channel that utilizesrepresentational state transfer (REST) hypertext transfer protocol(HTTP), hypertext transfer protocol (HTTP), simple object accessprotocol (SOAP), extensible markup language (XML), etc., messageformats. New mediums for the over-the-top (OTT) application interface210 may be defined and used, as appropriate, as long as applicationquality of service (QoS) message formats (i.e. attributes andcorresponding values included in application quality of servicemessages) conform minimally to application quality of service (QoS)message formats described herein (i.e. an application quality of service(QoS) request message format, an application quality of service (QoS)response message format, and an application quality of service (QoS)termination message format). As previously stated, the quality ofservice (QoS) server 100 uses a diameter Rx protocol (3GPP 29.214) tointerface 106 with a mobile network operator (MNO) policy and chargingrules function (PCRF) 104. A mobile network operator (MNO) policy andcharging rules function (PCRF) interface 106, as depicted in FIG. 2,provides discovery and addressing of a home policy and charging rulesfunction (HPCRF) 104 assigned to a requesting over-the-top (OTT)application/virtual private network (VPN) client device 108. The mobilenetwork operator (MNO) policy and charging rules function (PCRF)interface 106 is also enhanced to allow tracking registration of thefollowing IP header information: a virtual private network (VPN)security parameter index (SPI) (per RFC 2401, as required with IPSecprotocol by a virtual private network (VPN) client/server) and an IPSecprotocol (per RFC 2401).

In accordance with the principles of the present invention, the qualityof service (QoS) server 100 assumes the role of an application function(AF) and complies with policy and charging rules function (PCRF) 104discovery and addressing, as described in a 3GPP series 29.213specification. In support of this 3GPP series 29.213 specification, thequality of service (QoS) server 100 preferably maintains a table with afully qualified domain name (FQDN) or internet protocol (IP) address ofa policy and charging rules function (PCRF) 104, for each supportedsingle policy and charging rules function (PCRF) mobile network operator(MNO), and a diameter routing agent, for each supported multi-policy andcharging rules function (PCRF) mobile network operator (MNO).

The quality of service (QoS) server 100 interfaces with a home policyand charging rules function (HPCRF) 104, regardless as to whether or nota client user equipment (UE) 108 is roaming. A home policy and chargingrules function (HPCRF) 104 coordinates a download of quality of service(QoS) rules to a visiting policy and charging rules function (VPCRF) ina roaming network (per 3GPP standards) when a requesting client userequipment (UE) 108 is roaming.

In accordance with the principles of the present invention, numberportability databases (NPDB) 270 and the local mobile network operator(MNO) information database 230 (as shown in FIG. 2) support multipletransaction capabilities application part (TCAP) based protocols (e.g.,advanced intelligent network (AIN), intelligent network applicationprotocol (INAP), American national standards institute ((ANSI)-41),etc.) for number portability queries, since such protocols supportqueries from both wireline and wireless networks based on variousstandards. The quality of service (QoS) server 100 preferably uses anumber portability request (NPREQ) TCAP query (per telecommunicationsindustry association/electronic industries association (TIA/EIA)-756Aand telecommunications industry association/electronic industriesassociation (TIA/EIA) ANSI41-D specifications) to determine a currentmobile network operator (MNO) associated with an over-the-top (OTT)application client device 108. The quality of service (QoS) server 100may easily be extended to support other protocols for number portabilitylookup.

As previously stated, the quality of service (QoS) server 100 uses avirtual private network (VPN) client/server interface 116 to interfacewith a virtual private network (VPN) client 118 and/or a virtual privatenetwork (VPN) server 112. The virtual private network (VPN)client/server interface 116, as portrayed in FIG. 2, is designed tooperate over a secure transport layer security (TLS)/secure socketslayer (SSL) communications channel that utilizes representational statetransfer (REST) hypertext transfer protocol (HTTP), hypertext transferprotocol (HTTP), simple object access protocol (SOAP), extensible markuplanguage (XML), etc., message formats. The quality of service (QoS)server 100 may also/alternatively interface with a virtual privatenetwork (VPN) client 118 via a wireless network connection 260.

New mediums for the virtual private network (VPN) client/serverinterface 116 may be defined and used as appropriate, as long as VPNquality of service (QoS) message formats (i.e. attributes andcorresponding values included in VPN quality of service (QoS) messages)conform minimally to VPN quality of service (QoS) message formatsdescribed herein (i.e. a VPN quality of service (QoS) request messageformat, a VPN quality of service (QoS) response message format, and aVPN quality of service (QoS) termination message format). Depending uponthe implementation, a VPN quality of service (QoS) message mayadditionally be embedded in a defined message format, e.g., a radius ordiameter message format.

FIG. 3 depicts an exemplary process flow for extending quality ofservice (QoS) treatment to over-the-top (OTT) applications routing dataover a commercial wireless network via a virtual private network (VPN)tunnel, in accordance with the principles of the present invention.

In particular, as shown in step 1 a of FIG. 3, a virtual private network(VPN) tunnel performs VPN profile configuration with a quality ofservice (QoS) server 100 via an authenticated virtual private network(VPN) client/server interface 116. During virtual private network (VPN)profile configuration, a virtual private network (VPN) client/serverfurnishes relevant tunneling information to the quality of service (QoS)server 100 for a virtual private network (VPN) tunnel establishedtherebetween. Relevant tunneling information varies depending upon thetype of virtual private network (VPN) tunnel established.

In particular, a single-tenant virtual private network (VPN) tunnel 500provisions one or more quality of service (QoS) application profiles(and corresponding quality of service application profile IDs) on thequality of service (QoS) server 100 during VPN profile configuration. Aquality of service (QoS) application profile includes tunnelidentification details and indicates a desired level of quality ofservice (QoS) treatment.

Alternatively, a multi-tenant virtual private network (VPN) tunnel 520provisions identification details on the quality of service (QoS) server100 during VPN profile configuration, but need not provision any qualityof service application profiles. Rather, over-the-top (OTT) applications530 utilizing a multi-tenant virtual private network (VPN) tunnel 520provision their own quality of service (QoS) application profiles on thequality of service (QoS) server 100 during application profileconfiguration, performed in step 1 b. A quality of service (QoS)designation requested by an over-the-top (OTT) application transmittingdata over a multi-tenant virtual private network (VPN) tunnel 520 isassociated to that multi-tenant virtual private network (VPN) tunnel520.

In accordance with the principles of the present invention, amulti-tenant virtual private network (VPN) 520 tunnel must provideadequate tunneling information (including IPSec security policy andIPSec security association information) to the quality of service (QoS)server 100 during VPN profile configuration. Adequate tunnelinginformation is any information that enables the quality of service (QoS)server 100 to determine actual IP header information 440 associated withapplication data routed over the multi-tenant virtual private network(VPN) tunnel 520. Moreover, tunneling information must enable thequality of service (QoS) server 100 to adequately communicate quality ofservice (QoS) rules defined in a quality of service (QoS) requestmessage to a relevant policy and charging rules function (PCRF) 104.

Table 1 depicts exemplary tunneling information provided to the qualityof service (QoS) server during virtual private network (VPN) profileconfiguration.

TABLE 1 Security Association (Tunnel Header Information) Security PolicyInformation (For Encapsulated Traffic) Security IPSec IP IP IP FullySource Destination QoS- Parameter Protocol Destination SourceDestination Qualified Port Port Application- Index Address AddressAddress Domain Number Number Profile-ID Name

In particular, as portrayed in Table 1, IPSec security policyinformation (for encapsulated data traffic) and IPSec securityassociation information (tunnel header information) relevant to avirtual private network (VPN) tunnel is provided to the quality ofservice (QoS) server 100 during VPN profile configuration (step 1 a).Relevant IPSec security policy information preferably includes: an IPsource address, an IP destination address, a fully qualified domainname, a source port number, a destination port number, and a quality ofservice application profile ID. Relevant IPSec security associationinformation preferably includes: a security parameter index, an IPSecprotocol, and an IP destination address.

Updated tunneling information must be furnished to the quality ofservice (QoS) server 100 for each new virtual private network (VPN)tunnel that is established. In accordance with the principles of thepresent invention, tunneling information may either be preprovisioned onthe quality of service (QoS) server 100 during VPN profileconfiguration, or provided to the quality of service (QoS) server 100dynamically, via use of a VPN quality of service (QoS) registrationmessage.

As portrayed in step 1 b of FIG. 3, an application performs applicationprofile configuration on the quality of service (QoS) server 100 via anauthenticated over-the-top (OTT) application interface 210. Inaccordance with the principles of the present invention, an over-the-top(OTT) application must provide identification details and registerservices and application characteristics with a quality of service (QoS)server 100 before that application is permitted to request quality ofservice (QoS) treatment therefrom. For security purposes, the quality ofservice (QoS) server 100 only accepts registration attempts fromover-the-top (OTT) applications for which the quality of service (QoS)server 100 has been pre-configured to accept registration attempts.Therefore, not all over-the-top (OTT) applications are permitted toregister with a quality of service (QoS) server 100. Moreover,over-the-top (OTT) applications that are granted registration with aquality of service (QoS) server 100 are only permitted to receive levelsof quality of service (QoS) treatment for which they have beenpre-authorized to receive. Quality of service (QoS) requests arevalidated by the quality of service (QoS) server 100 before they areprocessed. An over-the-top (OTT) application also identifies serviceabilities and provisions one or more quality of service (QoS)application profiles on the quality of service (QoS) server 100 duringapplication profile configuration.

However, before an over-the-top (OTT) application can register andprovision quality of service (QoS) application profiles on the qualityof service (QoS) server 100, the quality of service (QoS) server 100must first collect the following data from the over-the-top (OTT)application (more characteristics may be required as new applicationcharacteristics present themselves): an over-the-top (OTT) applicationidentifier, over-the-top (OTT) access credentials, one or more qualityof service (QoS) application profile IDs, over-the-top (OTT) applicationcharacteristics, and one or more mobile network operator (MNO)associations.

In accordance with the principles of the present invention, anover-the-top (OTT) application identifier is a unique string(synchronized with a carrier provided “AF-Application-Identifier”) thatis provided to an over-the-top (OTT) application via an out-of-bandmechanism. An over-the-top (OTT) application identifier may be prefixedwith quality of service (QoS) unique identifiers for use on the qualityof service (QoS) server 100.

Over-the-top (OTT) access credentials (e.g. a secret/password or publickey infrastructure (PKI) verification) are a set of credentials agreedupon by an over-the-top (OTT) application and the quality of service(QoS) server 100 in an out of band manner.

A quality of service (QoS) application profile ID is a quality ofservice (QoS) specific value, defined per application identifier. Moreparticularly, the quality of service (QoS) application profile ID isdefined by the quality of service (QoS) server 100 and provided to anover-the-top (OTT) application via an out of band mechanism.

In accordance with the principles of the present invention, a quality ofservice (QoS) application profile ID points to a quality of service(QoS) application profile that is to be provisioned for an over-the-top(OTT) application. A quality of service (QoS) application profilecontains application details (e.g. service characteristics, etc.) andindicates a desired level of quality of service (QoS) treatment. Aquality of service (QoS) application profile ID is referenced in eachquality of service (QoS) request message sent to the quality of service(QoS) server 100, to indicate to the quality of service (QoS) server 100a particular quality of service (QoS) application profile to invoke. Inaccordance with the principles of the present invention, an over-the-top(OTT) application may provision multiple quality of service (QoS)application profiles to indicate varying levels of desired quality ofservice (QoS).

Over-the-top (OTT) application characteristics provided to the qualityof service (QoS) server 100 during application profile configurationinclude (this list may be extended as new requirements develop, eitherby 3GPP specifications or via over-the-top (OTT) evolution): a mediacomponent number (i.e. an ordinal number of a media component), a mediasub-component (i.e. a set of flows for one flow identifier), anapplication identifier, a media type (e.g. audio (0), video (1), data(2), application (3), control (4), text (5), message (6), other(0xFFFFFFFF)), a maximum requested bandwidth (Bw) uplink (UL), a maximumrequested bandwidth (Bw) downlink (DL), a flow status, a reservationpriority, RS bandwidth (Bw), RR bandwidth (Bw), codec data, and a tunnelencapsulation indicator, e.g., yes, no, IPSec, etc.

In accordance with the principles of the present invention, a mediasub-component field may include the following characteristics: a flownumber (i.e. an ordinal number of the IP flow), a flow description (e.g.uplink (UL) and/or downlink (DL)), a flow status, flow usage, a maximumrequested bandwidth (Bw) uplink (UL), a maximum requested bandwidth (Bw)downlink (DL), and an application function (AF) signaling protocol.

Moreover, a mobile network operator (MNO) associations field provided tothe quality of service (QoS) server 100 during application profileconfiguration identifies all of the networks for which an over-the-top(OTT) application is authorized to designate quality of service (QoS)settings. Values in a mobile network operator (MNO) associations fieldare defined per quality of service (QoS) implementation and representsystem logical identifiers for the purposes of routing communications toparticular policy and charging rules (PCRF) functions.

In accordance with the principles of the present invention, oncerequired application data is furnished to the quality of service (QoS)server 100, an over-the-top (OTT) application provisions one or morequality of service (QoS) application profiles on the quality of service(QoS) server 100. Following quality of service (QoS) application profileprovisioning, the over-the-top (OTT) application may begin submittingregistrations to the quality of service (QoS) server 100, on a per userequipment (UE) basis. In accordance with the principles of the presentinvention, an over-the-top (OTT) application is required to registerwith the quality of service (QoS) server 100 periodically.

Following application profile configuration, an over-the-top (OTT)application may send quality of service (QoS) requests to the quality ofservice (QoS) server 100, on a per user equipment (UE) basis.

As shown in steps 2 a and 2 b of FIG. 3, a virtual private network (VPN)tunnel 114 is established between a virtual private network (VPN) client118 on a user equipment (UE) 108 and a fixed infrastructure virtualprivate network (VPN) server 112, so as to allow data traffictransmitted to/from one or more over-the-top (OTT) application clients120 (that have undergone application profile configuration on thequality of service (QoS) server 100) on the user equipment (UE) 108 totraverse the tunnel 114.

In accordance with the principles of the present invention, the virtualprivate network (VPN) client 118/server 112 sends a VPN quality ofservice (QoS) registration message with appropriate tunnelinginformation to the quality of service (QoS) server 100 during VPN tunnelestablishment, as depicted in steps 3 a and 3 b of FIG. 3. Upon receiptof the VPN quality of service (QoS) registration message, the quality ofservice (QoS) server 112 returns a VPN quality of service (QoS)registration response message to the virtual private network (VPN)client 118/server 112, as depicted in steps 4 a and 4 b of FIG. 3. VPNtunneling information may alternatively be provisioned on the quality ofservice (QoS) server 100 during VPN profile configuration.

Once VPN registration with the quality of service (QoS) server 100 iscomplete, the virtual private network (VPN) client 118/server 112 maysend a VPN quality of service (QoS) request message to the quality ofservice (QoS) server 100 to request desired quality of service (QoS)treatment therefrom, as shown in steps 5 a and 5 b of FIG. 3.

In accordance with the principles of the present invention, VPN qualityof service (QoS) registration and request messages preferably include: amessage ID (i.e. an identifier defined by, and unique to, a requestingvirtual private network (VPN) server 112/client 118), a quality ofservice (QoS) application profile ID (optional), a publically availablemobile network assigned source framed internet protocol (IP) address (anattribute-value pair (AVP)) or framed IPv6 prefix (an attribute-valuepair (AVP), RFC 4005 [12]), a flow description (an attribute-value pair(AVP), 3GPP 29.214), a virtual private network (VPN) security parameterindex (SPI) (per RFC 2041, as required with IPSec protocol by thevirtual private network (VPN) client/server), an IPSec protocol (per RFC2041), a virtual private network (VPN) IP destination (i.e. a routableIP address for the virtual private network (VPN) server), and a VPN-CS.

A quality of service (QoS) application profile ID in a VPN quality ofservice (QoS) request message indicates a desired level of quality ofservice (QoS) treatment. A quality of service (QoS) application profileID is required in a VPN quality of service (QoS) request message whenthe message is provided to the quality of service (QoS) server 100dynamically. Otherwise, the quality of service (QoS) server 100 derivesa quality of service (QoS) application profile ID based on a combinationof values embedded in the VPN quality of service (QoS) request message.

A flow description is required in a VPN quality of service (QoS) requestmessage when a quality of service (QoS) application profile ID is notprovided therein. In accordance with the principles of the presentinvention, a flow description must comprise one of the following twodirections: ‘in’ or ‘out’, whereas direction ‘in’ refers to an uplink(UL) IP flow and direction ‘out’ refers to a downlink (DL) IP flow. Aflow description may also contain: a source and destination IP address(possibly masked), a protocol and a source and destination port (asource port may be omitted to indicate that any source port is allowed).Lists and ranges may not be used to indicate source and/or destinationports. In accordance with the principles of the present invention, thequality of service (QoS) server 100 accepts VPN quality of service (QoS)request messages from both a virtual private network (VPN) client 118and a virtual private network (VPN) server 112. Hence, depending uponthe implementation, some information may be missing from a VPN qualityof service (QoS) request message.

When both a virtual private network (VPN) server 112 and a virtualprivate network (VPN) client 118 send a VPN quality of service (QoS)request message to the quality of service (QoS) server 100 for a singleVPN connection 114, messages from each source must include a referenceto the other, to enable the quality of service (QoS) server 100 tosuccessfully assemble all relevant information and assign an appropriatequality of service (QoS) designation to over-the-top (OTT) applicationdata traversing the virtual private network (VPN) connection 114. AVPN-CS field is preferably used to provide such a reference.

In particular, when VPN quality of service (QoS) request messages aresent by both a virtual private network (VPN) server 112 and a virtualprivate network (VPN) client 118 for a single virtual private network(VPN) connection 114, optional attribute tag, ‘VPN-CS’ is preferablyincluded therein. Optional attribute tag ‘VPN-CS’ contains a uniquemessage identifier that is used by both a virtual private network (VPN)server 112 and a virtual private network (VPN) client 118, to show thatmessages refer to a single virtual private network (VPN) connection 114.

As shown in step 6 of FIG. 3, the quality of service (QoS) server 100performs VPN quality of service (QoS) request message validation inresponse to a VPN quality of service (QoS) request message receivedthereon. In particular, during VPN quality of service (QoS) requestmessage validation, the quality of service (QoS) server 100 validates aquality of service (QoS) application profile ID received in the VPNquality of service (QoS) request message.

In accordance with the principles of the present invention, the qualityof service (QoS) server 100 may either determine a quality of service(QoS) application profile ID directly or indirectly from the VPN qualityof service (QoS) request message. Indirect determination of a quality ofservice (QoS) application profile ID includes analyzing and matching VPNquality of service (QoS) request message parameters to an appropriatequality of service (QoS) application profile ID. Once a quality ofservice (QoS) application profile ID is determined, the quality ofservice (QoS) server 100 performs one of the following two potentialcourses of action, depending upon the type of virtual private network(VPN) tunnel 114 established in steps 2 a-4 b.

In particular, if the virtual private network tunnel (VPN) 114 is amulti-tenant virtual private network (VPN) tunnel 520, then the qualityof service (QoS) server 100 records and tracks virtual private network(VPN) 114 tunneling information received in the VPN quality of service(QoS) request message in a virtual private network (VPN) tunnelinginformation database 250, and subsequently returns a VPN quality ofservice (QoS) response message to the requesting virtual private network(VPN) client 118/server 112, as depicted in step 7. In accordance withthe principles of the present invention, the quality of service (QoS)server 100 then waits to receive an application quality of service (QoS)registration message or an application quality of service (QoS)termination message from an over-the-top (OTT) application routing orattempting to route data over the virtual private network (VPN) tunnel114.

In a multi-tenant virtual private network (VPN) scenario, if a qualityof service (QoS) application profile ID received in an applicationquality of service (QoS) request message differs from a quality ofservice (QoS) application profile ID embedded in a VPN quality ofservice (QOS) request message, the quality of service (QoS) applicationprofile ID in the application quality of service (QoS) request messageis used to influence quality of service (QoS) treatment.

Alternatively, if the virtual private network tunnel (VPN) 114established in steps 2 a-4 b is a single-tenant virtual private network(VPN) tunnel 500, then the quality of service (QoS) server 100immediately applies quality of service (QoS) rules received in the VPNquality of service (QoS) registration or request message to allapplication data routed over the virtual private network (VPN) tunnel114. The quality of service rules are extracted from the VPN quality ofservice (QoS) registration message if that is the only message receivedand VPN quality of services (QoS) request message if both are received.

In particular, when a VPN quality of service (QoS) registration (orrequest if received) message is received from a single-tenant virtualprivate network (VPN) client 118/server 112, the quality of service(QoS) server 100 queries a local mobile network operator (MNO)information database 230 to retrieve home mobile network operator (MNO)information for the over-the-top (OTT) application/virtual privatenetwork (VPN) client device 108, as depicted in step 8. If the qualityof service (QoS) server 100 cannot find home mobile network operator(MNO) information for the client device in the local mobile networkoperator (MNO) information database 230, then the quality of service(QoS) server 100 alternatively queries an external number portabilitydatabase (NPDB) 270 via a number portability database (NPDB) interface240. Results from either the number portability database (NPDB) 270 orthe local mobile network operator (MNO) information database 230 providethe quality of service (QoS) server 100 with enough information todetermine a home mobile network operator (MNO) for the over-the-top(OTT) application/VPN client device 108 (step 9).

Once a home mobile network operator (MNO) is identified, the quality ofservice (QoS) server 100 uses the quality of service (QoS) applicationprofile ID defined in the VPN quality of service (QoS) registration (orrequest if received) message to determine whether or not over-the-top(OTT) applications routing data over the virtual private network (VPN)tunnel are authorized to influence quality of service (QoS) treatment onthe home mobile network operator (MNO) (step 10). In this particularexample, there is only one over-the-top (OTT) application configured totransmit data over the virtual private network (VPN) tunnel 114.

In accordance with the principles of the present invention, if theover-the-top (OTT) application configured to route data over the virtualprivate network (VPN) tunnel 114 is permitted to influence quality ofservice (QoS) settings on the home mobile network operator (MNO), thenthe quality of service (QoS) server 100 sends a diameterauthentication/authorization request (AAR) message with appropriatequality of service (QoS) information to a policy and charging rulesfunction (PCRF) 104 on the client devices' 108 home mobile networkoperator (MNO), as shown in step 11.

In step 12, the policy and charging rules function (PCRF) 104 on theclient devices' 108 home mobile network operator (MNO) receives thequality of service (QoS) information and returns a diameterauthentication/authorization answer (AAA) message to the quality ofservice (QoS) server 100.

Upon receipt of the diameter authentication/authorization answer (AAA)message, the quality of service (QoS) server 100 sends a VPN quality ofservice (QoS) response message to the requesting VPN client 118/server112, as depicted in step 13.

In accordance with the principles of the present invention, a VPNquality of service (QoS) response message preferably includes: a messageID, an application identifier, and a status identifier. A statusidentifier included in a status field of a VPN quality of service (QoS)response message may be any one or more of the following: a successstatus identifier (100), a quality of service (QoS) system failurestatus identifier (200) (indicating a default failure or unexpectedfailure with no available details), a failed validation of applicationidentifier/access credentials status identifier (201), a failedvalidation of quality of service (QoS) profile ID status identifier(202), a quality of service (QoS) system failure reserved message statusidentifier (defined per quality of service (QoS) implementation and usedto explain a unique system failure) (203-299), a PCRF unavailable statusidentifier (300), and/or an AAR/AAA message failure status identifier(400), wherein the entire contents of the AAA message is embedded in thestatus field.

Once the virtual private network (VPN) tunnel 114 is setup between thevirtual private network (VPN) client 118 on the user equipment 108 andthe virtual private network (VPN) server 112, the over-the-top (OTT)application client 120 configured to route data over the virtual privatenetwork (VPN) tunnel 114 may use the virtual private network (VPN)tunnel 114 to register with a corresponding over-the-top (OTT)application server 110 (via a Gi/SGi interface 310), as shown in steps14 a and 14 b of FIG. 3.

When the over-the-top (OTT) application server 110 receives a serviceregistration request from the over-the-top (OTT) application client 120,the over-the-top (OTT) application server 110 may attempt to establish amutually authenticated (client 120 and server 110) transport layersecurity (TLS)/secure sockets layer (SSL) connection with the inventivequality of service (QoS) server 100 (via standard TLS/SSL procedures formutual authentication), as shown in step 15.

If the initial mutual authentication step is successful, then theover-the-top (OTT) application server 110 sends an application qualityof service (QoS) request message to the quality of service (QoS) server100 to request that a desired level of quality of service (QoS)treatment be applied to application data routed by that over-the-top(OTT) application over the virtual private network (VPN) tunnel 114, asportrayed in step 16.

In accordance with the principles of the present invention, a quality ofservice (QoS) request message preferably includes: a message ID (i.e. anidentifier defined by, and unique to, a requesting over-the-top (OTT)application), an application identifier (as described in 3GPP series29.214 specification), access credentials (e.g. a secret/password publickey infrastructure (PKI) verification, etc.), a quality of service (QoS)application profile ID, a source framed internet protocol (IP) address(an attribute-value pair (AVP)) or framed IPv6 prefix (anattribute-value pair (AVP), RFC 4005 [12]), a service uniform resourcename (URN) (an attribute-value pair (AVP), 3GPP 29.214), a reservationpriority (TS 183.017 [15]) (a vendor ID shall be set to europeantelecommunications standards institute (ETSI) (13019) [15]), asubscription ID (RFC 4006 [14]) identifying a particular subscription(e.g. international mobile subscriber identity (IMSI), mobile subscriberintegrated services digital network (MSISDN), etc.), and a flowdescription (an attribute-value pair (AVP), 3GPP 29.214).

A flow description in an application quality of service (QoS) requestmessage must comprise one of the following two directions: ‘in’ or‘out’, whereas direction ‘in’ refers to an uplink (UL) IP flow anddirection ‘out’ refers to a downlink (DL) IP flow. A flow description inan application quality of service (QoS) request message may alsocontain: a source and destination IP address (possibly masked), aprotocol, and a source and destination port (a source port may beomitted to indicate that any source port is allowed). Lists and rangesmay not be used to indicate source and/or destination ports.

A quality of service (QoS) application profile ID in an applicationquality of service (QoS) request message indicates appropriate qualityof service (QoS) information to send to a home policy and charging rulesfunction (PCRF) 104.

In accordance with the principles of the present invention, the qualityof service (QoS) server 100 performs application quality of service(QoS) request message validation in response to an application qualityof service (QoS) request message received thereon, as portrayed in step17 of FIG. 3.

During application quality of service (QoS) request message validation,the quality of service (QoS) server 100 validates the applicationidentifier, access credentials (e.g. a secret/password public keyinfrastructure (PKI) verification, etc.), and quality of service (QoS)application profile ID received in the application quality of service(QoS) request message, against application profiles maintained in alocal application information database 220. The quality of service (QoS)server 100 validates the format and values of application quality ofservice (QoS) request message attributes in accordance with a 3GPPseries 29.214 specification.

When application quality of service (QoS) request message validation iscomplete, the quality of service (QoS) server 100 queries a local mobilenetwork operator (MNO) information database 230 to retrieve home mobilenetwork operator (MNO) information for the requesting over-the-top (OTT)application client device 108, as depicted in step 18. If the quality ofservice (QoS) server 100 cannot find home mobile network operator (MNO)information for the requesting client device 108 in the local mobilenetwork operator (MNO) information database 230, then the quality ofservice (QoS) server 100 alternatively queries an external numberportability database (NPDB) 270 via a number portability database (NPDB)interface 240. Results from either the number portability database(NPDB) 270 or the local mobile network operator (MNO) informationdatabase 230 provide the quality of service (QoS) server 100 with enoughinformation to determine a home mobile network operator (MNO) for therequesting client device 108.

Once a home mobile network operator (MNO) is identified (step 19), thequality of service (QoS) server 100 uses a quality of service (QoS)application profile ID, defined in the application quality of service(QoS) request message, to determine whether or not the requestingover-the-top (OTT) application is authorized to influence quality ofservice (QoS) treatment on the home mobile network operator (MNO).

In step 20 of FIG. 3, if the over-the-top (OTT) application is permittedto influence quality of service (QoS) settings on the home mobilenetwork operator (MNO), then the quality of service (QoS) server 100queries a local virtual private network (VPN) tunneling informationdatabase 250 to determine actual IP packet information associated withapplication data routed by the over-the-top (OTT) application over thevirtual private network (VPN) tunnel 114.

In step 21 of FIG. 3, the quality of service (QoS) server 100 sends adiameter authentication/authorization request (AAR) message withappropriate quality of service (QoS) information and appropriate IPtunneling data to a policy and charging rules function (PCRF) 104 on theclient devices' 108 home mobile network operator (MNO). Appropriatequality of service (QoS) information depends on the type of virtualprivate network (VPN) tunnel 114 routing data.

In particular, if the virtual private network (VPN) tunnel 114 is asingle-tenant virtual private network (VPN) tunnel 520, then thediameter authentication/authorization request (AAR) message assignsquality of service (QoS) rules defined in the application quality ofservice (QoS) request message to all application data routed over thevirtual private network (VPN) tunnel 114, as previously described insteps 11-13. This assignment allows mapping to the application qualityof service (QoS) request message.

Rather, if the virtual private network (VPN) tunnel 114 is amulti-tenant virtual private network (VPN) tunnel 500, then the qualityof service (QoS) server 100 assigns quality of service (QoS) rulesdefined in the application quality of service (QoS) request message toapplication data being routed for the requesting over-the-top (OTT)application, only. In particular, the quality of service (QoS) server100 sends a diameter authentication/authorization request (AAR) messagewith appropriate quality of service (QoS) rules and appropriate tunnelpacket identification information to a policy and charging rulesfunction (PCRF) 104 on the client devices 108 home mobile networkoperator (MNO). Tunnel packet identification information sent to thepolicy and charging rules function (PCRF) must enable the policy andcharging rules function (PCRF) to identify which tunnel packets toassign the requested quality of service (QoS) designation.

As portrayed in step 22, the policy and charging rules function (PCRF)104 on the client devices' 108 home mobile network operator (MNO)receives quality of service (QoS) information and returns a diameterauthentication/authorization answer (AAA) message to the quality ofservice (QoS) server 100.

In step 23, the quality of service (QoS) server 100 sends a quality ofservice (QoS) application response message with an appropriate statusvalue to the over-the-top (OTT) application server 110.

In accordance with the principles of the present invention, a quality ofservice (QoS) application response message preferably comprises: amessage ID, an application identifier, and a status identifier.

A status identifier included in a status field of a quality of service(QoS) application response message may be any one or more of thefollowing: a success status identifier (100), a quality of service (QoS)system failure status identifier (200) (indicating a default failure orunexpected failure with no available details), a failed validation ofapplication identifier/access credentials status identifier (201), afailed validation of quality of service (QoS) profile ID statusidentifier (202), a quality of service (QoS) system failure reservedmessage status identifier (defined per quality of service (QoS)implementation and used to explain a unique system failure) (203-299), aPCRF unavailable status identifier (300), and/or an AAR/AAA messagefailure status identifier (400), wherein the entire contents of the AAAmessage is embedded in the status field.

Once quality of service (QoS) rules have been forwarded to the policyand charging rules function (PCRF) 104 on the client devices' 108 homemobile network operator (MNO), the over-the-top (OTT) application client120 can proceed to transmit and consume data for service deliverypurposes (i.e. the over-the-top (OTT) client 120 delivers a service asavailable to its' functionality and thereby consumes IP bandwidth as aresult of service fulfillment). In particular, as depicted in steps 24 aand 24 b of FIG. 3, the over-the-top (OTT) application client 120 on theuser equipment 108 either initiates or receives a request to beginservice fulfillment.

As shown in step 25, once a request for service fulfillment is received(or initiated) on the over-the-top (OTT) application server 110 (via aGi/SGi interface 310), the over-the-top (OTT) application server 110attempts to establish a mutually authenticated (client 120 and server110) transport layer security (TLS)/secure sockets layer (SSL)connection with the quality of service (QoS) server 100 (followingstandard transport layer security (TLS)/secure sockets layer (SSL)procedures for mutual authentication).

As portrayed in step 26, if the initial mutual authentication step issuccessful, the over-the-top (OTT) application server 110 sends anapplication quality of service (QoS) request message over the virtualprivate network (VPN) tunnel 114 to the quality of service (QoS) server100, to request that a desired level of quality of service (QoS)treatment be applied to application data routed by the over-the-top(OTT) application over the virtual private network (VPN) tunnel 114.

As depicted in steps 27-33, the quality of service (QoS) server 100 thenperforms application quality of service (QoS) request message validationon the received application quality of service (QoS) request message,identifies a home mobile network operator (MNO) for the requestingclient user equipment (UE) 108, sends appropriate quality of service(QoS) data to a home policy and charging rules function (PCRF) 104 basedon the type of virtual private network (VPN) tunnel 114 routingapplication data, and subsequently forwards a quality of service (QoS)application response message to the over-the-top (OTT) applicationserver 110, as previously described in steps 17-23.

In accordance with the principles of the present invention, oncesignaling or data services are terminated on the over-the-top (OTT)application client device 108, the over-the-top (OTT) application server110 informs the quality of service (QoS) server 100 of the servicetermination, to trigger reserved quality of service (QoS) values to beterminated on the client devices' 108 home mobile network operator(MNO).

In particular, as depicted in step 34 of FIG. 3, when the over-the-top(OTT) application server 110 detects a termination of signaling orservice on the over-the-top (OTT) application client user equipment (UE)108, the over-the-top (OTT) application server 110 attempts to establisha mutually authenticated (client 120 and server 110) TLS/SSL connectionwith the quality of service (QoS) server 100 (following standard TLS/SSLprocedures for mutual authentication).

As portrayed in step 35, if the initial mutual authentication step issuccessful, the over-the-top (OTT) application server 110 sends anapplication quality of service (QoS) termination message to the qualityof service (QoS) server 100.

In accordance with the principles of the present invention, anapplication quality of service (QoS) termination message preferablyincludes: a message ID (an identifier defined by, and unique to, arequesting over-the-top (OTT) application), an application identifier(as described in 3GPP series 29.214 specification), access credentials(e.g. a secret/password public key infrastructure (PKI) verification,etc.), a quality of service (QoS) application profile ID, a sourceframed IP address (an attribute-value part (AVP)) or framed IPv6 prefix(an attribute-value part (AVP), RFC 4005 [12]), a service uniformresource name (URN) (an attribute-value part (AVP), 3GPP 29.214), areservation priority (TS 183.017 [15]) (a vendor is preferably set toeuropean telecommunications standards institute (ETSI) (13019) [15]),and a subscription ID (RFC 4006 [14]), identifying a particularsubscription, e.g., international mobile subscriber identity (IMSI),mobile station integrated services digital network (MSISDN), etc.

In response to an application quality of service (QoS) terminationmessage, the quality of service (QoS) server 100 performs applicationquality of service (QoS) termination message validation, as portrayed instep 36. During application quality of service (QoS) termination messagevalidation, the quality of service (QoS) server 100 validates theapplication identifier and access credentials (e.g., a secret/passwordpublic key infrastructure (PKI) verification, etc.) received in theapplication quality of service (QoS) termination message againstapplication profile data maintained in a local application informationdatabase 220.

As depicted in step 37, once application quality of service (QoS)termination message validation is complete, the quality of service (QoS)server 100 sends a diameter session termination request (STR) message tothe policy and charging rules function (PCRF) 104 on the over-the-top(OTT) application client device's 108 home mobile network operator(MNO), to indicate that service/signaling has been terminated.

In steps 38 and 39, the policy and charging rules function (PCRF) 104responds to the quality of service (QoS) server 100 with a diametersession termination answer (STA) message, and the quality of service(QoS) server 100 subsequently sends an application quality of service(QoS) response message (including an appropriate status value) to therequesting over-the-top (OTT) application server 110.

Similarly, the virtual private network (VPN) client 118 and/or server112 sends an IPSec tunnel mapping table, containing appropriate tunneltermination information (tunneling information depicted in Table 1) tothe quality of service (QoS) server 100, once the virtual privatenetwork (VPN) tunnel 114 is terminated.

In particular, as depicted in steps 40 a, 40 b, and 40 c, the virtualprivate network (VPN) client 118/server 112 sends a VPN quality ofservice (QoS) termination message with appropriate tunneling information(tunneling information depicted in Table 1) to the quality of service(QoS) server 100 when the virtual private network (VPN) tunnel 114 isterminated. The virtual private network (VPN) client 118 sends a VPNquality of service (QoS) termination message to the quality of service(QoS) server 100 via a conventional Gi/SGi interface 310.

In accordance with the principles of the present invention, a VPNquality of service (QoS) termination message preferably includes accesscredentials and a tunnel source and destination IP address, to enablethe quality of service (QoS) server to identify which tunnel is beingterminated and to determine if a pending quality of service (QoS)configuration in the wireless network need be removed as a result of thetunnel termination. A quality of service (QoS) termination message istypically preceded by a session termination. However, this may notalways be the case.

In step 41, the quality of service (QoS) server 100 receives the VPNquality of service (QoS) termination message and appropriately respondsto the virtual private network (VPN) client 118/server 112 with a VPNquality of service (QoS) response message.

Many commercial wireless networks provide quality of service (QoS) totheir clients. The inventive solution is described herein via use of aspecific long term evolution (LTE) network provider. However, thepresent invention may be applied to any wireless network that supportsquality of service (QoS) treatment, including: a universal mobiletelecommunications system (UMTS), long term evolution (LTE) technology,an evolved-universal mobile telecommunications system (E-UMTS), longterm evolution (LTE) technology advanced, and Wi-Fi.

Inventive quality of service (QoS) logic may and should be extended tosupport other scenarios, such as scenarios described as “ApplicationFunction” logic in 3GPP series 29 specifications.

Use of this inventive technology causes certain packets associated witha virtual private network (VPN) connection to be identified via theirsecurity parameter index (SPI) value. Identification of this nature mayreveal an associative characteristic of some virtual private network(VPN) packets. Implementers of the inventive technology may wish todetermine if additional security, additional encryption, etc., isrequired to compensate for the reveal of the associative nature ofpackets.

The present invention has particular applicability to United Statesfederal agencies, such as the Federal Emergency Management Agency(FEMA), and the Department of Homeland Security (DHS), etc., as well asto emergency first responders, large over-the-top (OTT) applicationproviders (e.g., Google™, Apple™, etc.), and enhanced long termevolution (LTE) policy and charging rules function(s) (PCRF), frompolicy and charging rules function (PCRF) vendors.

While the invention has been described with reference to the exemplaryembodiments thereof, those skilled in the art will be able to makevarious modifications to the described embodiments of the inventionwithout departing from the true spirit and scope of the invention.

1-49. (canceled)
 50. A method for extending quality of service (QoS)treatment to an over-the-top (OTT) application transmitting data over acommercial wireless network via a virtual private network (VPN) tunnel,comprising: receiving a VPN quality of service (QoS) request messagefrom an over-the-top (OTT) application server; performing validation onsaid VPN quality of service (QoS) request message; determining that saidover-the-top (OTT) application server is permitted to change a qualityof service (QoS) setting on a home mobile network operator (MNO) server;tracking virtual private network (VPN) tunneling information receivedwith said VPN quality of service (QoS) request message; overridingcurrent quality of service (QoS) rules with quality of service (QoS)rules embedded in said VPN quality of service (QoS) request message; androuting a message to a policy and charging rules (PCRF) server to assignquality of service (QoS) rules defined in said VPN quality of service(QoS) request message to all application data routed over said virtualprivate network (VPN) tunnel; wherein said virtual private network (VPN)tunnel is a single-tenant virtual private network (VPN) tunnel.
 51. Themethod for extending quality of service (QoS) treatment to anover-the-top (OTT) application transmitting data over a commercialwireless network via a virtual private network (VPN) tunnel according toclaim 50, further comprising: querying an external number portabilitydatabase (NPDB) for home mobile network operator (MNO) information whenhome mobile network operator (MNO) information cannot be found by saidhome mobile network operator (MNO) server.
 52. The method for extendingquality of service (QoS) treatment to an over-the-top (OTT) applicationtransmitting data over a commercial wireless network via a virtualprivate network (VPN) tunnel according to claim 50, wherein: said policyand charging rules function (PCRF) server provides conventional qualityof service (QoS) treatment to said over-the-top (OTT) applicationtransmitting data over said virtual private network (VPN) tunnel. 53.The method for extending quality of service (QoS) treatment to anover-the-top (OTT) application transmitting data over a commercialwireless network via a virtual private network (VPN) tunnel according toclaim 50, further comprising: transmitting said quality of serviceinformation to said policy and charging rules function (PCRF) via adiameter protocol interface.
 54. The method for extending quality ofservice (QoS) treatment to an over-the-top (OTT) applicationtransmitting data over a commercial wireless network via a virtualprivate network (VPN) tunnel according to claim 50, further comprising:forwarding, via said policy and charging rules function (PCRF) on saidhome mobile network operator (MNO), received quality of service (QoS)rules to a policy and charging rules function (PCRF) serving saidover-the-top (OTT) application client device when said (OTT) applicationclient device is roaming.
 55. The method for extending quality ofservice (QoS) treatment to an over-the-top (OTT) applicationtransmitting data over a commercial wireless network via a virtualprivate network (VPN) tunnel according to claim 50, wherein: said VPNquality of service (QoS) request message indicates a particular qualityof service (QoS) profile to invoke.
 56. The method for extending qualityof service (QoS) treatment to an over-the-top (OTT) applicationtransmitting data over a commercial wireless network via a virtualprivate network (VPN) tunnel according to claim 50, wherein: saidover-the-top (OTT) application server sends an application quality ofservice (QoS) termination message to said quality of service (QoS)server when said over-the-top (OTT) application server detects at leastone of a termination of service, and a termination of signaling, on anover-the-top (OTT) application client device.
 57. The method forextending quality of service (QoS) treatment to an over-the-top (OTT)application transmitting data over a commercial wireless network via avirtual private network (VPN) tunnel according to claim 56, wherein:said application quality of service (QoS) termination message indicatesto said quality of service (QoS) server that reserved quality of service(QoS) values may be terminated on said home mobile network operator(MNO) assigned to said over-the-top (OTT) application client device. 58.A method for extending quality of service (QoS) treatment to anover-the-top (OTT) application transmitting data over a commercialwireless network via a virtual private network (VPN) tunnel, comprising:receiving a VPN quality of service (QoS) request message from anover-the-top (OTT) application server; performing validation on said VPNquality of service (QoS) request message; determining that saidover-the-top (OTT) application is permitted to change a quality ofservice (QoS) setting on a home mobile network operator (MNO) server;tracking virtual private network (VPN) tunneling information receivedwith said VPN quality of service (QoS) request message; overridingcurrent quality of service (QoS) rules with quality of service (QoS)rules embedded in said VPN quality of service (QoS) request message; androuting a message to a policy and charging rules (PCRF) server to assignquality of service (QoS) rules defined in said VPN quality of service(QoS) request message to all application data routed for said requestingover-the-top (OTT) application; wherein said virtual private network(VPN) tunnel is a multi-tenant virtual private network (VPN) tunnel. 59.The method for extending quality of service (QoS) treatment to anover-the-top (OTT) application transmitting data over a commercialwireless network via a virtual private network (VPN) tunnel according toclaim 58, further comprising: querying an external number portabilitydatabase (NPDB) for home mobile network operator (MNO) information whenhome mobile network operator (MNO) information cannot be found by saidhome mobile network operator (MNO) server.
 60. The method for extendingquality of service (QoS) treatment to an over-the-top (OTT) applicationtransmitting data over a commercial wireless network via a multi-tenantvirtual private network (VPN) tunnel according to claim 58, wherein:said policy and charging rules function (PCRF) server providesconventional quality of service (QoS) treatment to said over-the-top(OTT) application transmitting data over said virtual private network(VPN) tunnel.
 61. The method for extending quality of service (QoS)treatment to an over-the-top (OTT) application transmitting data over acommercial wireless network via a multi-tenant virtual private network(VPN) tunnel according to claim 58, further comprising: transmittingsaid quality of service information to said policy and charging rulesfunction (PCRF) via a diameter protocol interface.
 62. The method forextending quality of service (QoS) treatment to an over-the-top (OTT)application transmitting data over a commercial wireless network via amulti-tenant virtual private network (VPN) tunnel according to claim 58,further comprising: forwarding, via said policy and charging rulesfunction (PCRF) on said home mobile network operator (MNO), receivedquality of service (QoS) rules to a policy and charging rules function(PCRF) serving said over-the-top (OTT) application client device whensaid (OTT) application client device is roaming.
 63. The method forextending quality of service (QoS) treatment to an over-the-top (OTT)application transmitting data over a commercial wireless network via amulti-tenant virtual private network (VPN) tunnel according to claim 58,wherein: said VPN quality of service (QoS) request message indicates aparticular quality of service (QoS) profile to invoke.
 64. The methodfor extending quality of service (QoS) treatment to an over-the-top(OTT) application transmitting data over a commercial wireless networkvia a multi-tenant virtual private network (VPN) tunnel according toclaim 58, wherein: said over-the-top (OTT) application server sends anapplication quality of service (QoS) termination message to said qualityof service (QoS) server when said over-the-top (OTT) application serverdetects at least one of a termination of service, and a termination ofsignaling, on an over-the-top (OTT) application client device.
 65. Themethod for extending quality of service (QoS) treatment to anover-the-top (OTT) application transmitting data over a commercialwireless network via a multi-tenant virtual private network (VPN) tunnelaccording to claim 64, wherein: said application quality of service(QoS) termination message indicates to said quality of service (QoS)server that reserved quality of service (QoS) values may be terminatedon said home mobile network operator (MNO) assigned to said over-the-top(OTT) application client device.
 66. A method for extending quality ofservice (QoS) treatment to an over-the-top (OTT) applicationtransmitting data over a commercial wireless network via a virtualprivate network (VPN) tunnel, comprising: receiving a VPN quality ofservice (QoS) request message from an over-the-top (OTT) applicationserver; performing validation on said VPN quality of service (QoS)request message; determining that said over-the-top (OTT) application ispermitted to change a quality of service (QoS) setting on a home mobilenetwork operator (MNO) server; tracking virtual private network (VPN)tunneling information received with said VPN quality of service (QoS)request message; overriding current quality of service (QoS) rules withquality of service (QoS) rules embedded in said VPN quality of service(QoS) request message; and routing a message to a policy and chargingrules (PCRF) server to assign quality of service (QoS) rules defined insaid VPN quality of service (QoS) request message to all applicationdata routed for said requesting over-the-top (OTT) application; whereinsaid virtual private network (VPN) tunnel is a multi-tenant virtualprivate network (VPN) tunnel.
 67. A method for extending quality ofservice (QoS) treatment to an over-the-top (OTT) applicationtransmitting data over a commercial wireless network via a virtualprivate network (VPN) tunnel according to claim 66, further comprising:querying an external number portability database (NPDB) for home mobilenetwork operator (MNO) information when home mobile network operator(MNO) information cannot be found by said home mobile network operator(MNO) server.
 68. A method for extending quality of service (QoS)treatment to an over-the-top (OTT) application transmitting data over acommercial wireless network via a virtual private network (VPN) tunnelaccording to claim 66, further comprising: transmitting said quality ofservice information to said policy and charging rules function (PCRF)via a diameter protocol interface.
 69. A method for extending quality ofservice (QoS) treatment to an over-the-top (OTT) applicationtransmitting data over a commercial wireless network via a virtualprivate network (VPN) tunnel according to claim 66, further comprising:forwarding, via said policy and charging rules function (PCRF) on saidhome mobile network operator (MNO), received quality of service (QoS)rules to a policy and charging rules function (PCRF) serving saidover-the-top (OTT) application client device when said (OTT) applicationclient device is roaming.